Modern computer graphics, the kind often seen in movies and computer-generated artwork, consist of two-dimensional (2D) images or image sequences (movies) that are derived from complex 3D data. The 3D scene data includes the 3D coordinates of every object in a scene. Since the images derived from the scene are intended to show a realistic representation of actual 3D objects, the scene data also includes definitions, called "shaders," that represent surface and volume properties of each object. The shaders dictate how light is reflected, refracted, and scattered by the objects. Shaders can also be defined for volumes of space (e.g., a puff of smoke) or the entire scene environment, the latter being called an environmental shader.
To make the realistic image, the 3D scenes are rendered. The process of rendering involves ray-tracing which determines the look of each pixel visible from the camera viewpoint. In ray-tracing, the effects of occultation and diffuse and specular reflection, refraction, and diffusion of light by the various objects and volumes in the scene are determined. Ray tracing not only accounts for primary effects which are the reflections, refractions, and diffusions of light arriving directly from the light sources, but also for secondary reflections. The latter result when primary light from other objects illuminates, or passes through, an object or volume. These secondary effects can involve multiple reflections, refractions, or transmissions between the original light source and the camera so that, considering that rays must be traced for every pixel in a scene, and considering that some shaders involve complex numerical algorithms, the process of rendering can be extremely time consuming for current computer technology.
Referring to FIG. 1, when an author creates and edits a 3D scene the author edits the scene data that defines 3D objects. Typically, the feedback provided to the author is an unrealistic wire-frame view of the scene. A typical editing environment may show (on a display screen 10) a perspective wire-frame view 40 in a separate window. Other wire-frame views may also be shown, for example a top view 60. The wire frame views 40, 60 show objects as they appear in perspective 30, 50 or as the objects appear in a top view. Also forming part of the editing environment are various tools used to define the shaders and other properties in the scene. For example, an object may be selected and a shader editor 20 invoked to define or modify the shaders applied to the selected object. The shader editor has various controls 25 to adjust the various shader properties of the object. The various objects defined in the scene can also be moved and their sizes adjusted, for example, by using control points on the wire-frames. The wire-frame views may also display, and allow editing of, so-called "3D manipulators" which allow editing of non-physical objects and effects that have 3D attributes. For example, the cone of projection of a light source can be resized, moved, or rotated by manipulating a corresponding 3D manipulator.
While working in the above-described authoring (or editing) context, the author can see, in near real time, the effects of some of the changes. For example, when an object's wire-frame is moved, the wire-frame image is updated immediately. To see the rendering effects of the artist's work, however, the artist must request a rendering of the scene data. This changes the context of the user interface to a preview context 70 in which the author is disconnected from the editing tools. Once the author has waited for, and inspected, the rendered image, the author can return to the editing context and access the object manipulators, shader editors, etc. This situation, where the artist is working in one context, the editing context, and seeing the actual image in another context, can be limiting because it does not provide full and immediate feedback to the artist. For example, imagine modeling a dinosaur walking and trying to make subtle adjustments to the skin texture. The author must remember the way the skin looked, tweak some parameter, and inspect the result. Some editing environments allow the author to store multiple images and juxtapose them in a different framework, a picture viewer or editor, for example. However, this slows down the process of editing and takes the author through multiple steps and different environments.
Currently, in 2D drawing- and bitmap-editing programs and word-processors, the developer is able to work in an environment that shows the results of modifications almost immediately. This is the so-called, what-you-see-is-what-you-get (WYSIWYG) feature. At first blush, it might seem desirable to provide this feature for graphic artists and animators working with complex 3D models. However, the rendering process, which is what provides the author with such critical information, is so computationally-intensive, that performance would be unacceptably degraded in a hypothetical WYSIWYG environment, given the limitations of current and near term hardware technology. Waiting for images to be updated would impose delays between each step implemented by the author.
On the other hand, for 3D scenes, conventional authoring environments are superior in some ways to what would be available in a WYSIWYG environment. The wire-frame views and object property-defining tools display abstracted information about the scene that provides, in some cases, more information than a realistic rendering. For example, objects with 3D attributes that are almost invisible in a rendering can be seen clearly in a wireframe view. Also, wire-frame views can show guides that can be helpful in providing perspective. Rendered views often contain little contrast at the boundaries of objects. This is not a problem with wire-frames views. So the idea of bringing WYSIWYG to a 3D editing environment appears not only impractical, it also appears to involve some sacrifices. The invention addresses both of these drawbacks of the prior art.